Some Interdisciplinary Observations about Getting the "Right" Specification

One can use formal approaches either post facto to try to show that a program has desirable properties or one can aim for verified by construction (VxC). The former approach tends to focus on specific properties such as avoiding the de-referencing of null pointers; the latter is more likely to address the question of whether the steps of design satisfy some overall specification. I not only prefer the latter but I have also argued that this is the main way to get formal methods to pay off: there is more mileage in getting a clean architecture than in trying to debug a bad design by retrofitting a proof. I think VxC is also a way to choose an appropriate level of formality perhaps using outline arguments and filling in details if doubt arises (see [Jon96]; Jackson and Wing made a similar point in the same journal; [Jon05] makes a similar point related to proofs). But we must also face the crucial question " how do we know that the specification is right? ". This is not a trivial question especially with the way computers are used today. As computers have become more powerful and less expensive, they have become ever more deeply embedded in the way nearly everyone works. In their short history, computers have moved from batch processors in their own buildings to work tools on every desk (or lap). They are now essential components of administration, retail trade, banking and vehicles; computers in the future will become invisible dust sprinkled on who-knows-what. This has transformed the task of understanding the requirements of a system. Above all, the close interaction of people with computer systems makes it essential that designers consider the whole system when formulating a specification of the technical parts. This larger system involves people as essential components. Model-oriented specification techniques like VDM, Z, ASMs and B have an enormous amount in common; among other things shared by this formal methods community is the view that one can start with a formal specification and show that a design/implementation satisfies that specification. It is obvious however that, if a specification does not actually reflect the real need, proving a program correct with respect to it is somewhat pointless. Am I arguing in favour of " XP " or fluid prototyping? Certainly not — at least not for most applications. But one might have to proceed in this way …